home *** CD-ROM | disk | FTP | other *** search
/ QRZ! Ham Radio 4 / QRZ Ham Radio Callsign Database - Volume 4.iso / digests / digital / 940194.txt < prev    next >
Internet Message Format  |  1994-11-13  |  20KB
  1. Date: Tue, 14 Jun 94 04:30:13 PDT
  2. From: Ham-Digital Mailing List and Newsgroup <ham-digital@ucsd.edu>
  3. Errors-To: Ham-Digital-Errors@UCSD.Edu
  4. Reply-To: Ham-Digital@UCSD.Edu
  5. Precedence: Bulk
  6. Subject: Ham-Digital Digest V94 #194
  7. To: Ham-Digital
  8.  
  9.  
  10. Ham-Digital Digest          Tue, 14 Jun 94       Volume 94 : Issue  194
  11.  
  12. Today's Topics:
  13.              An open note to Gary Coffman, KE4ZV (6 msgs)
  14.                      Need info on Ottawa PI Card
  15.                         Packet Ideas Sought...
  16.                    Thenet Eprom 1X for Thenet Node
  17.                 TM-733A and 9600 baud packet (3 msgs)
  18.  
  19. Send Replies or notes for publication to: <Ham-Digital@UCSD.Edu>
  20. Send subscription requests to: <Ham-Digital-REQUEST@UCSD.Edu>
  21. Problems you can't solve otherwise to brian@ucsd.edu.
  22.  
  23. Archives of past issues of the Ham-Digital Digest are available 
  24. (by FTP only) from UCSD.Edu in directory "mailarchives/ham-digital".
  25.  
  26. We trust that readers are intelligent enough to realize that all text
  27. herein consists of personal comments and does not represent the official
  28. policies or positions of any party.  Your mileage may vary.  So there.
  29. ----------------------------------------------------------------------
  30.  
  31. Date: Mon, 13 Jun 94 08:07:56 EDT
  32. From: world!mv!lmr!rapp@uunet.uu.net
  33. Subject: An open note to Gary Coffman, KE4ZV
  34. To: ham-digital@ucsd.edu
  35.  
  36. Erich Franz Stocker <stocker@spsosun.gsfc.nasa.gov> writes:
  37.  
  38. ... stuff deleted
  39. ( Using Packet nodes for Internet nodes doesn't hold much appeal for me
  40. either, although, there's nothing wrong with saving money!)
  41.  
  42. > While I can appreciate the BBS services of packet.  I have to question
  43. > this as a main purpose in amateur radio. I'd like to see packet
  44. > turn into a more real time "communications" avenue.  Logging into a
  45. > mail box isn't really radio.
  46.  
  47. I disagree, Erich.  I think it's as much a part of radio as contesting,
  48. dxing, experimenting - all those different modes.  Frankly, it seems to me
  49. that traffic handling and bbs's are the thing for which packet is most
  50. suited.  Voice communications seem to me to be far more efficient for real
  51. time.  This based on holding a ticket for 40 years now and getting into just
  52. about everything I could. :)
  53.  
  54. 73,
  55.  
  56. Larry W1HJF
  57.  
  58. -----------------------------------------------------------------------------
  59. L. M. Rappaport &  Associates, Inc.   rapp@lmr.mv.com   voice +1 603 237 8400
  60. Colebrook, NH  03576-0158             CIS 72427,2567    fax   +1 603 237 8430
  61.  
  62. ------------------------------
  63.  
  64. Date: 13 Jun 1994 12:58:32 GMT
  65. From: ihnp4.ucsd.edu!usc!howland.reston.ans.net!gatech!concert!news-feed-1.peachnet.edu!news.duke.edu!godot.cc.duq.edu!codger!broderic@network.ucsd.edu
  66. Subject: An open note to Gary Coffman, KE4ZV
  67. To: ham-digital@ucsd.edu
  68.  
  69. Chris Mcmahon (packman@cix.compulink.co.uk) wrote:
  70. : > I'm aware that TCP/IP is already available.  But this is a suite of
  71. : > programs which operate only through packet, if I'm not mistaken. > 
  72. : Ideally,any program which can run through standard TCP/IP should be able
  73. : > to run through a packet-radio version of TCP/IP.  As far as I know, 
  74. : this > is not currently the case.
  75.  
  76. : I've made the same comment to some of the TCP/IP fanatics in this area.  
  77. : They seem to be happy with the various flavours of NOS/NET that exist.  
  78. : I'd like to add some 'features' to NOS, but I get put off by having to 
  79. : try and figure out what the impact of my changes will be on the 350 (ish) 
  80. : source code files that comprise JNOS (for example).  What I'd ideally 
  81. : like is a TCP/IP stack as a TSR that can have one or many hardware 
  82. : drivers plugged into the bottom end and then present a standard API to 
  83. : the programming world.  Then standard telnet, etc could be used on top of 
  84. : the TSR and I could write software using the API without having to worry 
  85. : about messing up any of the underlying code.  One possibility that could 
  86. : be used, although I've not explored it, is some of the Winsock software.  
  87. : Unfortunately that means learning to write sensible Windows programs :-(  
  88. : I'm talking 'IBM PC world' here, but the same could easily apply to other 
  89. : environments.
  90. ...... more deleted
  91. : Chris - G6FCI Packet   : G6FCI @ GB7FCI.#16.GBR.EU
  92. : Internet : packman@cix.compulink.co.uk
  93.  
  94. I was recently surprised to see references to ka9q code in a package
  95. of Ftp Software's PC/TCP for dos.  This package comes with some 
  96. winsock stuff (I think...), and although the source isn't available, one
  97. might coax an ax25 packet driver into working with it.  I suspect that 
  98. this is typical of many dos networking packages.
  99.  
  100. As far as other computing environments, work done for Sunos, and recently
  101. Linux, points in this direction-- these provide kernel-layer interfaces
  102. to the ax.25 world.  The chalenge now exists to write software to 
  103. bridge between where packet users are today (mostly store/forward bbs
  104. style systems) to something a bit more transparent.
  105.  
  106. Don Broderick N3GUZ
  107.  
  108. ------------------------------
  109.  
  110. Date: Mon, 13 Jun 1994 15:06:26 GMT
  111. From: ihnp4.ucsd.edu!usc!howland.reston.ans.net!europa.eng.gtefsd.com!emory!rsiatl!ke4zv!gary@network.ucsd.edu
  112. Subject: An open note to Gary Coffman, KE4ZV
  113. To: ham-digital@ucsd.edu
  114.  
  115. In article <X8XuNc7w165w@lmr.mv.com> rapp@lmr.mv.com (Larry Rappaport) writes:
  116. >Erich Franz Stocker <stocker@spsosun.gsfc.nasa.gov> writes:
  117. >> While I can appreciate the BBS services of packet.  I have to question
  118. >> this as a main purpose in amateur radio. I'd like to see packet
  119. >> turn into a more real time "communications" avenue.  Logging into a
  120. >> mail box isn't really radio.
  121. >
  122. >I disagree, Erich.  I think it's as much a part of radio as contesting,
  123. >dxing, experimenting - all those different modes.  Frankly, it seems to me
  124. >that traffic handling and bbs's are the thing for which packet is most
  125. >suited.  Voice communications seem to me to be far more efficient for real
  126. >time.  This based on holding a ticket for 40 years now and getting into just
  127. >about everything I could. :)
  128.  
  129. I agree with Larry, realtime "chat" mode is about the worst use for
  130. packet. We have other modes that are much better suited to this type
  131. of use. Packet is useful for the things it can do better than other
  132. modes, and store and forward is a primary example of where packet
  133. is superior to other modes. Packet does that well, but it isn't a 
  134. substitute for a microphone when the need is for realtime person to
  135. person communications. Hopefully, as the network speed increases,
  136. realtime machine to machine communications will become an important
  137. application facilitator, but right now non-realtime store and forward 
  138. is the niche best served by packet.
  139.  
  140. Gary
  141. -- 
  142. Gary Coffman KE4ZV          |    You make it,     | gatech!wa4mei!ke4zv!gary
  143. Destructive Testing Systems |    we break it.     | uunet!rsiatl!ke4zv!gary
  144. 534 Shannon Way             |    Guaranteed!      | emory!kd4nc!ke4zv!gary 
  145. Lawrenceville, GA 30244     |                     | 
  146.  
  147. ------------------------------
  148.  
  149. Date: 13 Jun 1994 12:31:10 -0700
  150. From: mdisea!not-for-mail@uunet.uu.net
  151. Subject: An open note to Gary Coffman, KE4ZV
  152. To: ham-digital@ucsd.edu
  153.  
  154. In article <X8XuNc7w165w@lmr.mv.com>, Larry Rappaport <rapp@lmr.mv.com> wrote:
  155.  
  156. >suited.  Voice communications seem to me to be far more efficient for real
  157. >time.
  158.  
  159. Maybe from the standpoint of the user but not from the standpoint of channel
  160. usage. There's a reason the phone companies have gone digital /:) What we
  161. ought to have is packet voice!
  162.  
  163. -=-=-=-=-=-=-=-=-=-=-=-=-==-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
  164. Hugh Shane                | 206 487 5909 (PST)
  165. Motorola Wireless Data    | N7UAX 
  166. shane@mdd.comm.mot.com    | #include <std_disclaimer.h>
  167. -=-=-=-=-=-=-=-=-=-=-=-=-==-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
  168.  
  169. ------------------------------
  170.  
  171. Date: 13 Jun 1994 21:13:03 GMT
  172. From: ihnp4.ucsd.edu!swrinde!gatech!newsxfer.itd.umich.edu!zip.eecs.umich.edu!yeshua.marcam.com!news.kei.com!ssd.intel.com!chnews!cmoore@network.ucsd.edu
  173. Subject: An open note to Gary Coffman, KE4ZV
  174. To: ham-digital@ucsd.edu
  175.  
  176. Hugh Shane (shane@mdd.comm.mot.com) wrote:
  177.  
  178. : There's a reason the phone companies have gone digital
  179. : Hugh Shane                | 206 487 5909 (PST)
  180.  
  181. Hi Hugh, last time I checked, the initial deployment of IS-54 (digital)
  182. was no more bandwidth efficient than NAMPS (analog). And GSM (digital)
  183. is worse than NAMPS.
  184.  
  185. 73, KG7BK, OOTC, CecilMoore@delphi.com
  186.  
  187. ------------------------------
  188.  
  189. Date: 14 Jun 1994 00:36:33 GMT
  190. From: koriel!newsworthy.West.Sun.COM!abyss.West.Sun.COM!spot!myers@ames.arpa
  191. Subject: An open note to Gary Coffman, KE4ZV
  192. To: ham-digital@ucsd.edu
  193.  
  194. In article 685@microsoft.com, davidar@microsoft.com (David Arnold) writes:
  195.  
  196. >However, there are going to be some who will not want to dedicate a PC
  197. >to the problem.  The problem can be solved in software, but the software
  198. >solution would only solve a particular platform configuration.
  199. >For example, if someone were to write a AX.25 NDIS driver, that would
  200. >solve the problem for a MS-DOS TCP/IP stack which support NDIS at the bottom,
  201. >which, BTW, is probably very common.
  202.  
  203. Not a bad idea.  In the System V world, an AX.25 Streams module would be
  204. cool, though a really good one would allow both AX.25 sessions and
  205. other networking sessions, and would be a multiplexor module, not as
  206. easy as a straight AX.25/IP module.  NDIS should be pretty straightforward,
  207. though I have to write an NDIS driver.
  208.  
  209. >Can you imagine running PC Mosiac for an Amateur Radio WWW?
  210.  
  211. No.  Well, on second thought, I can.  It would suck.  Here's a :-) for those
  212. who need it.
  213.  
  214. ---
  215.  * Dana H. Myers KK6JQ, DoD#: j    | Views expressed here are    *
  216.  * (310) 348-6043         | mine and do not necessarily    *
  217.  * Dana.Myers@West.Sun.Com    | reflect those of my employer    *
  218.  * This Extra supports the abolition of the 13 and 20 WPM tests *
  219.  
  220. ------------------------------
  221.  
  222. Date: Mon, 13 Jun 1994 21:39:35 GMT
  223. From: microsoft!wingnut!davidar@uunet.uu.net
  224. Subject: Need info on Ottawa PI Card
  225. To: ham-digital@ucsd.edu
  226.  
  227. Where can I get one, company contact names, etc.
  228.  
  229. Thanks.
  230.  
  231. davidar@microsoft.com
  232. KD6IFY
  233.  
  234. ------------------------------
  235.  
  236. Date: 14 Jun 1994 02:15:46 GMT
  237. From: ihnp4.ucsd.edu!dog.ee.lbl.gov!agate!darkstar.UCSC.EDU!news.hal.COM!olivea!news.bu.edu!dartvax.dartmouth.edu!usenet@network.ucsd.edu
  238. Subject: Packet Ideas Sought...
  239. To: ham-digital@ucsd.edu
  240.  
  241.      I'm thinking this summer about what I might want to do for a
  242. senior thesis in computer science next year, and I've decided that if
  243. it is possible, I would like to do something involving packet radio. 
  244. Im still trying to think of something to do, however.  I have a few
  245. thoughts:
  246.      The focus of whatever I do is probably going to revolve around the
  247. nature of the amateur network as a fairly slow one (1200-9600 baud with
  248. rare exception.)  It is also currently almost entirely accessed through
  249. text based terminal programs.  There are a few specialty products on
  250. the market, but these are all most entirely specialty terminal
  251. programs. So, I could possibly explore something about the nature of
  252. the interface used to access the services in the network.  I could
  253. possibly explore the use of something like an X Window system or
  254. similar open protocol for graphically-oriented distributed,
  255. client-server programs.  
  256.      Or I could possibly explore the netwrk for another angle, and ask
  257. the question "what services should be provided and how can they be best
  258. provided?"  "What sort of changes/enhancements in the network will be
  259. the most beneficial to the user community?"  Is there something like
  260. hypertext that will greatly improve the nature of the network?
  261.      If you have any thoughts on this, I would appreciate it if you
  262. would drop me a line, or start up a general discussion of it here.  I'm
  263. just sort of collecting thoughts at this stage, so anything might help.
  264.      Also, if anyone knows of a good source for technical documentation
  265. on AX.25 or TCP/IP or the packet network in general, I would appreciate
  266. the pointers.
  267.      Thanks and 73's...
  268.  
  269. ---
  270. =======================================================================
  271. Kenneth E. Harker  N1PVB        Dartmouth College  Amateur Packet Radio
  272. kenneth.e.harker@dartmouth.edu  Hinman Box 1262    n1pvb@w1et.nh.usa.na
  273. (603) 643-5716                  Hanover, NH 03755  or n1pvb-5 on 144.99
  274. =======================================================================
  275.              (PGP Public Key now available on request)
  276.  
  277. ------------------------------
  278.  
  279. Date: 14 Jun 1994 08:55:09 GMT
  280. From: ihnp4.ucsd.edu!swrinde!howland.reston.ans.net!xlink.net!scsing.switch.ch!swidir.switch.ch!univ-lyon1.fr!lanpc1.univ-lyon1.fr!cerdini@network.ucsd.edu
  281. Subject: Thenet Eprom 1X for Thenet Node
  282. To: ham-digital@ucsd.edu
  283.  
  284.  I'm looking for contents of Thenet Eprom 1X for Thenet Node (data which are
  285.  loaded in TNC eprom)... Someone know where I can found that ?
  286.  
  287. --
  288. Michel CERDINI - Universite Lyon 1      |  E-Mail cerdini@lan1.univ-lyon1.fr
  289. Laboratoire d'Analyse Numerique URA 740 | Tel Pro 72 43 10 93 -     aka Djoe
  290. 43, boul. du 11 novembre 1918           | Minitel 78 36 19 96 (24h/24)     v
  291. 69622 Villeurbanne Cedex, France.       |  Modem  78 36 10 01 (V-Fast)   _/
  292.  
  293. ------------------------------
  294.  
  295. Date: 13 Jun 1994 15:29:04 GMT
  296. From: ihnp4.ucsd.edu!usc!nic-nac.CSU.net!charnel.ecst.csuchico.edu!olivea!ncd.com!newshost.ncd.com!hansen.ncd.com!phil@network.ucsd.edu
  297. Subject: TM-733A and 9600 baud packet
  298. To: ham-digital@ucsd.edu
  299.  
  300. I have a TM-733A and I would like to talk with others who are currently using
  301. it for 9600 baud packet...
  302.  
  303. I would like to know what TXdelay you are running.  I seem to have to keep
  304. TXDelay at 18... Which seems long.  Other than that... It seems to work
  305. perfectly!
  306.  
  307. Phil
  308. de kj6nn
  309.  
  310. ------------------------------
  311.  
  312. Date: 13 Jun 1994 16:08:50 GMT
  313. From: news.larc.nasa.gov!arbd0.larc.nasa.gov!zawodny@ames.arpa
  314. Subject: TM-733A and 9600 baud packet
  315. To: ham-digital@ucsd.edu
  316.  
  317. In article <2thu00$18f$1@rosebud.ncd.com> phil@hansen.ncd.com (Phil Graham) writes:
  318. >I have a TM-733A and I would like to talk with others who are currently using
  319. >it for 9600 baud packet...
  320. >
  321. >I would like to know what TXdelay you are running.  I seem to have to keep
  322. >TXDelay at 18... Which seems long.  Other than that... It seems to work
  323. >perfectly!
  324. >
  325.  
  326. Wow!  I'd love to be able to set my TXDelay at 18 (180ms).  I currently have to
  327. set it to 40 with my GE Custom MVP.  Anyone got any ideas how I can speed my
  328. MVP up?  How about mods for 9600 buad?
  329.  
  330.  
  331. -- 
  332.  Joseph M. Zawodny   (KO4LW)                    NASA Langley Research Center
  333.  Internet: zawodny@arbd0.larc.nasa.gov          MS-475, Hampton VA, 23681-0001
  334.  Packet:   ko4lw@n4hog.va.usa
  335.  
  336. ------------------------------
  337.  
  338. Date: 13 Jun 1994 20:59:15 GMT
  339. From: usc!howland.reston.ans.net!gatech!newsxfer.itd.umich.edu!zip.eecs.umich.edu!yeshua.marcam.com!charnel.ecst.csuchico.edu!olivea!ncd.com!newshost.ncd.com!hansen.ncd.com!phil@ihnp4.ucsd.edu
  340. Subject: TM-733A and 9600 baud packet
  341. To: ham-digital@ucsd.edu
  342.  
  343. I thought that most 9600 baud folks were trying to run with a TX delay of 7 to
  344. 9 (aka 70 to 80 ms)...
  345.  
  346. How about it... What is common for 9600 baud?
  347.  
  348. phil
  349. de kj6nn
  350.  
  351. In article <2ti0ai$f9p@reznor.larc.nasa.gov>, zawodny@arbd0.larc.nasa.gov (Joseph M Zawodny) writes:
  352. |> In article <2thu00$18f$1@rosebud.ncd.com> phil@hansen.ncd.com (Phil Graham) writes:
  353. |> >I have a TM-733A and I would like to talk with others who are currently using
  354. |> >it for 9600 baud packet...
  355. |> >
  356. |> >I would like to know what TXdelay you are running.  I seem to have to keep
  357. |> >TXDelay at 18... Which seems long.  Other than that... It seems to work
  358. |> >perfectly!
  359. |> >
  360. |> 
  361. |> Wow!  I'd love to be able to set my TXDelay at 18 (180ms).  I currently have to
  362. |> set it to 40 with my GE Custom MVP.  Anyone got any ideas how I can speed my
  363. |> MVP up?  How about mods for 9600 buad?
  364.  
  365. ------------------------------
  366.  
  367. Date: Mon, 13 Jun 1994 15:09:52 GMT
  368. From: world!dts@uunet.uu.net
  369. To: ham-digital@ucsd.edu
  370.  
  371. References <2tf0kb$rql@eldborg.rhi.hi.is>, <1994Jun12.140915.1245@ke4zv.atl.ga.us>, <wb6wCrB332.H3o@netcom.com>dts
  372. Subject : Re: info wanted: new Kantronics 9k6 modem
  373.  
  374. In article <wb6wCrB332.H3o@netcom.com> wb6w@netcom.com (Glenn Thomas) writes:
  375. >Gary Coffman (gary@ke4zv.atl.ga.us) wrote:
  376. >: In article <2tf0kb$rql@eldborg.rhi.hi.is> bnt@rhi.hi.is (Benedikt Sveinsson) writes:
  377. >: >Hello.
  378. >: >I was just hearing about the new Kantronics 9k6 packet
  379. >: >modem. I saw the advertisment in QST, but no price or 
  380. >: >free the MFJ from the packet only operation on my BBS.
  381. >
  382. >: The Kantronics 9600 baud modem is a G3RUH copy, like the MFJ
  383. >: and the PacComm. The only difference is in form factor of the 
  384. >: card to fit the different TNCs. Street price is in the range 
  385. >: of $87-$109 at most shows. Aside from kludging the packaging,
  386. >: your MFJ 9600 baud modem will work in the KAM.
  387. >
  388. >: Gary
  389. >
  390. >Actually, I don't think the KAM can do 9600 at all. I asked the Kantronics rep
  391. >about the KAM and 9600 and was told that the KAM does its HDLC processing in
  392. >software rather than the hardware implementation that the TAPR II and clones
  393. >use. The software is fine for 1200 baud and slower, but just can't handle
  394. >9600. The Kantronics data engine does work very well at 9600 and a G3RUH
  395. >clone ought to work well in an TNC II clone.
  396. >
  397. >Oh...I understand that the KPC-3 also does HDLC in software, so it will never
  398. >do 9600 either.
  399.  
  400. Kantronics has just announced a new box that handles one port for 9600 packet
  401. and another for 1200 packet. The HDLC framing is in software. Keep in mind that
  402. there is absolutely nothing wrong with using a software solution. It allows
  403. a MUCH simpler method for providing fixes should a problem be found. Suppose
  404. you find a bug in an HDLC-capable SCC chip? The usual answer to that is to
  405. live with it...
  406.  
  407. I'm looking forward to trying one of the new Kantronics 9600 boxes...
  408.  
  409. Dan N1JEB
  410.  
  411. -- 
  412. ---------------------------------------------------------------
  413. Daniel Senie                 Internet:     dts@world.std.com
  414. Daniel Senie Consulting                    n1jeb@world.std.com
  415. 508-779-0439                 Compuserve:   74176,1347
  416.  
  417. ------------------------------
  418.  
  419. Date: Mon, 13 Jun 1994 12:43:59 GMT
  420. From: ihnp4.ucsd.edu!swrinde!emory!rsiatl!ke4zv!gary@network.ucsd.edu
  421. To: ham-digital@ucsd.edu
  422.  
  423. References <2tf0kb$rql@eldborg.rhi.hi.is>, <1994Jun12.140915.1245@ke4zv.atl.ga.us>, <wb6wCrB332.H3o@netcom.com>
  424. Reply-To : gary@ke4zv.atl.ga.us (Gary Coffman)
  425. Subject : Re: info wanted: new Kantronics 9k6 modem
  426.  
  427. In article <wb6wCrB332.H3o@netcom.com> wb6w@netcom.com (Glenn Thomas) writes:
  428. >
  429. >Actually, I don't think the KAM can do 9600 at all. I asked the Kantronics rep
  430. >about the KAM and 9600 and was told that the KAM does its HDLC processing in
  431. >software rather than the hardware implementation that the TAPR II and clones
  432. >use. The software is fine for 1200 baud and slower, but just can't handle
  433. >9600. The Kantronics data engine does work very well at 9600 and a G3RUH
  434. >clone ought to work well in an TNC II clone.
  435. >
  436. >Oh...I understand that the KPC-3 also does HDLC in software, so it will never
  437. >do 9600 either.
  438.  
  439. Hmm. Good point Glenn. I used real TNC2 type TNCs when I was using
  440. TNCs. I had forgotten that the Kantronics boxes are gutless wonders.
  441. Still, I do know that the Kantronics 9600 baud modem that fits the
  442. Data Engine (and the Gracillis PacketTwin) is a G3RUH clone, and will
  443. work with MFJ and PacComm TNCs, though it's physically the wrong shape
  444. to fit in the cases.
  445.  
  446. Gary
  447. -- 
  448. Gary Coffman KE4ZV          |    You make it,     | gatech!wa4mei!ke4zv!gary
  449. Destructive Testing Systems |    we break it.     | uunet!rsiatl!ke4zv!gary
  450. 534 Shannon Way             |    Guaranteed!      | emory!kd4nc!ke4zv!gary 
  451. Lawrenceville, GA 30244     |                     | 
  452.  
  453. ------------------------------
  454.  
  455. End of Ham-Digital Digest V94 #194
  456. ******************************
  457.